Looking for What Isn’t Officially There

C ommercial relationships and business contracts, which formally express the rights and obligations binding a client and a supplier, provide the inspiration for design by contract software development methodology. Software contracts take the form of routine preconditions (obligations on the caller), postconditions (benefits to the caller), and class invariants (consistency constraints), written into the program itself. The design by contract methodology uses such contracts for building each software element. This approach is particularly appropriate for developing safety-critical software and for reusable libraries. The Ariane 5 accident makes a textbook case for the precision that design by contract offers in specifying reusable components. The methodology is a key design element of some existing libraries, especially the Eiffel software development environment, which incorporates contract mechanisms in the programming language itself. As long-time practitioners of design by contract techniques, we see their benefits clearly and are surprised that recent languages and libraries, including the official libraries for Java and .NET and the C++ Standard Template Library, have not adopted them. Because we see the contract metaphor as inherent to quality software development, we undertook the work reported here as a sanity check: Do we see contracts everywhere simply because our development environment makes using them natural? Or are they intrinsically present, even when other designers don’t express or even perceive them? To answer these questions, we examined noncontracted libraries for hidden contracts—that is, for language or documentation techniques that suggest contract mechanisms such as precondition and postcondition clauses. Our first target is the Collections classes of the .NET Framework Class Library, the most recent addition to the world’s collection of fundamental data structure and algorithm libraries.